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(54) Secure database 

(57) A secure database system comprises a server 
having a database including at least one personal infor- 
mation table and at least one further table containing 
information relating to the persons whose details are 
stored in the personal information table. The keys of the 
tables in the database are unrelated, so that it is impos- 
sible to determine solely from information in the server 
which record in the further table corresponds to which 



record in the personal information table. Thus, even if a 
hacker obtains access to the database, the hacker will 
not be able to relate information in the different tables. 
Each legitimate client uses an encryption process to 
convert a personal identifier value, which identifies the 
record relating to a particular person in the personal in- 
formation table, into a pseudo-identifier value, which 
identifies a record relating to the same person in the fur- 
ther table. 
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Description 

Background to the invention 

This invention relates to secure databases. 

Many countries have legislation for controlling the 
way in which personal data may be stored and used on 
computer systems. For example, the Dutch Personal 
Data Registration Act ("Wet Persoonsregistraties") de- 
mands (among other things) that the database must be 
secured against hackers who have succeeded in getting 
unauthorised access to the database despite all security 
applied to it. However, it has been found that conven- 
tional database systems do not satisfy this requirement. 
For example, in conventional hospital information sys- 
tems, if a hacker gains access to a medical history 
record, the hacker can obtain the patient's key from this 
record and use this key to access any other records con- 
taining information about the same patient, such as the 
patient's name and address. 

The object of the present invention is to provide a 
way of overcoming this problem. 

Summary of the Invention 

According to the invention a computer system com- 
prises: 

(a) a server having a database including at least one 
personal information table and at least one further 
table containing information relating to persons 
whose details are stored in the personal information 
table; and 

(b) a plurality of clients, for accessing said data- 
base; 

(c) said tables in said database having keys that are 
unrelated to each other, whereby it is impossible to 
determine solely from information in the server 
which record in said further table corresponds to 
which record in said personal information table; and 

(d) each client including an encryption process for 
converting a personal identifier value, which identi- 
fies a record relating to a particular person in said 
personal information table, into a pseudo-identifier 
value, which identifies a record relating to the same 
person in said further table. 

It can be seen that, even if a hacker obtains access 
to the database, the hacker will not be able to relate in- 
formation in the different tables. In a hospital information 
system for example, if a hacker obtains access to a med- 
ical history record, the hacker cannot relate this record 
to a particular patient. 

Brief Description of the Drawing 

Figure 1 is a block diagram showing a computer 
system incorporating a secure database. 



Figure 2 shows a skeleton model of the database. 
Description of an Embodiment of the Invention 

s One embodiment of the invention will now be de- 
scribed by way of example with reference to the accom- 
panying drawings. This consists of a hospital records 
system which stores information about patients and 
their treatments, and which can only be accessed by au- 

10 thorised users, such as doctors, nurses and administra- 
tors. However, it will be appreciated that the invention 
can also be used in other applications where there is a 
need to protect personal data. For example, the inven- 
tion could also be used in an insurance company data- 

is base for storing personal data about customers and de- 
tails about their claims. 

Overall view of the system 

20 Referring to Figure 1 , this shows a distributed com- 
puter system comprising a server 10 and a number of 
clients 11, interconnected by a network 12. The server 
is a central hospital computer, and the clients are per- 
sonal computers (PCs), located on individual users' 

25 desks. The server 10 runs a database application 13, 
which may be any database system; for example, it may 
be an Oracle database. Each client 11 runs a client ap- 
plication 14, which enables an authorised user to com- 
municate with the database, and to access data from it. 

30 Referring to Figure 2, the database 13 holds a 
number of tables. Each of these tables has a primary 
key (indicated by "pk n ), which uniquely identifies each 
record in the table. This primary key is a numeric figure, 
starting with 1 (one) for the first record written in the table 

35 and incremented by 1 (one) for each subsequent record 
inserted into that table. Some of the tables also include 
foreign keys (indicated by "fk"), which identify connec- 
tions between the tables. 

There are two groups of tables. The first group con- 

40 tains personal data about patients and users, and the 
data defining the periods of care. Only the data in this 
group is required in order to establish if a user is allowed 
to access the records for a particular patient. This group 
comprises the lollowing tables: 

45 

Patient Personal, non-medical data about indi- 

vidual patients, such as the patient's 
name, address and telephone number. 

so User Information about authorised users of 

the system. The information includes 
such things as name, login name, and 
doctor's specialism. 

ss CarePeriod Information about which users are cur- 
rently responsible for the care of individ- 
ual patients. 
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The second group ol tables holds medical data. It 
consists of a large number of tables, each of which holds 
one and only one group of facts. Some examples ot ta- 
bles in this second group are as follows: 

Registration Information about registration of indi- 
vidual patients. There is one row in 
this table for each patient currently un- 
der active care. 

Appointment Information about appointments that 
have been arranged for individual pa- 
tients. 

Medication I nformation about medication that has 
been prescribed for individual pa- 
tients. 

PatientNote Free-text medical notes on individual 
patients. 

Each of the tables in this second group has a pri- 
mary key which is in no way related to the primary keys 
of the patient or user. Therefore, even if a hacker man- 
ages to obtain access to one of these tables, it is not 
possible for the hacker to relate the medical data to a 
particular patient or user. 

To enable authorised users to relate the information 
in this second group of tables to the patients or users, 
the system uses so-called pseudo-identifiers (PIDs). 
The PIDs are stored in extra columns of the tables. The 
PID values are calculated from the patients' and users' 
primary keys : using a cryptographic algorithm. The cryp- 
tographic algorithm is available only on the clients; the 
algorithm is not recorded in the database, and so cannot 
be discovered by a hacker who gains access to the serv- 
er. The algorithm uses a master encryption key, which 
is different for each hospital. 

The PID values are calculated using a different en- 
cryption protocol for each PID in each table. This is 
achieved by assigning a unique identifier number 
nr_PI D to each PI D in each table, and using this n umber 
as an input parameter for the cryptographic algorithm. 
In other words, the encryption algorithm for a particular 
PID uses the following three parameters: 

the primary key being encrypted, 

the hospital's master encryption key. 

the unique identifier number nr_PID for the PID. 

Thus, it is guaranteed that records relating to the 
same patient have different PID values in different ta- 
bles, and records with the same PID in different tables 
do not relate to the same patient. 

For example, in the database of Figure 2, unique 
identifier numbers nr_PID may be assigned to the PIDs 
as follows: 
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Free-text columns in the database, such as in the 
PatientNote table, present a particular problem, since a 
user is free to put any text in these columns, and may 
therefore include the patient's name. This would be of 
great assistance to a hacker. This problem is overcome 
by storing such free text in encrypted form, using an en- 
cryption algorithm resident on the client. 

Login 

This section describes the operation of the system 
when a user logs in. 

The client application first prompts the user to enter 
his or her login name and password, and sends a login 
message to the database application. When the data- 
base application receives this message, it authenticates 
the user. Techniques for authentication of users are well 
known, and so will not be described in any further detail. 

Assuming that the user has been correctly authen- 
ticated, the database application then searches the Us- 
er table, to find the record that matches the user's login 
name. From this record, the database application ob- 
tains the user's primary key. 

The client application then encrypts the user's pri- 
mary key, using the appropriate nr_PID (34 for example) 
as a parameter, to generate a user PID value for access- 
ing the CarePeriod table. The PID is sent to the data- 
base application. 

The database application then searches the 
CarePeriod table, to find all rows containing this PID. 
This identifies all the patients currently in the care of this 
particular user. The database application then uses the 
patient keys from these rows to access the correspond- 
ing rows of the Patient table. The patients' personal de- 
tails are read from the Patient table, and are returned to 
the client application where they are displayed to the 
user. 

Medication table 

This section describes the operation of the system 
when a user wishes to obtain details of a particular pa- 
tient's medication. It is assumed that the user has 
logged in to the system and has obtained the patient's 
primary key as described above. 

The client application encrypts the patient's primary 
key, using the appropriate nr_PID (47 for example) as a 
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parameter, so as to generate a patient PID value for ac- 
cessing the Registration table. The patient PID is sent 
to the database application. 

The database application searches the Registration 
table to find the row that contains this patient PID value. 
It then uses the Registration key from this row to access 
the corresponding row in the Medication table. The med- 
ication record of the patient is then read from this row, 
and is returned to the client application, for displaying 
to the user. 

Appointment table 

This section describes the operation of the system 
when a user wishes to obtain details of a patient's ap- 
pointments with a particular doctor. It is assumed that 
the user has logged in to the system and has obtained 
the patient's primary key as described above. 

The user primary key for the doctor is first read from 
a look-up table into the client application. 

The client application then encrypts the patient pri- 
mary key, using the appropriate nr_PID (47 for example) 
as a parameter, so as to generate a patient PID value 
for accessing the Registration table. The client applica- 
tion also encrypts the user primary key, using the appro- 
priate nr_PID (23 for example) as a parameter, so as to 
generate a user PID value for accessing the Registra- 
tion table. The calculated PID values are sent to the da- 
tabase application. 

The database application then searches the Regis- 
tration table, to find a row containing both of these PID 
values. It then uses the Registration primary key from 
this row to access the corresponding row in the Appoint- 
ments table. Details of the appointment are then read 
from this row, and returned to the client application, for 
displaying to the user. 

PatientNote table 

This section describes the operation of the system 
when a user wishes to view a free-text note relating to 
a particular patient. It is assumed that the user has 
logged in to the system and has obtained the patient's 
primary key as described above. 

The client application first encrypts the patient pri- 
mary key, using the appropriate nr_PID (47 for example) 
as a parameter, so as to generate a patient PID value 
for accessing the Registration table. The PID is sent to 
the database application. 

The database application then searches the Regis- 
tration table, to find the row that contains this patient PID 
value. It then uses the Registration primary key from this 
row to access the corresponding row in the PatientNote 
table. This row contains the (encrypted) free-form text 
notes relating to the patient, and is returned to the client 
application. The client application then decrypts the 
notes, and displays them to the user. 

The user can also update the text, or create new 



text, using a conventional word processor. The client ap- 
plication encrypts this text, and sends it to the database 
application, for writing into the PatientNote table. 

s Network encryption 

Preferably, all traffic over the network 12 is encrypt- 
ed, to protect it against eavesdropping. It should be not- 
ed that this encryption is additional to the encryption 
io processes described above. Encryption techniques for 
networks are well known, and so will not be described 
in any further detail in this specification. 

Some possible modifications 

It will be appreciated that many modifications may 
be made to the system described above without depart- 
ing from the scope of the present invention. For exam- 
ple, instead of using the same encryption algorithm for 
all the tables, a different encryption algorithm may be 
used for each table. 

The login procedure may be enhanced with some 
sort of software for user authentication. This process will 
involve an extra database server. It is envisaged that the 
authentication process will, on a positive authentication, 
return the encryption key or keys to be used by the client 
application to calculate the required PIDs. 



Dmputer system comprising: 

(a) a server having a database including at 
least one personal information table and at 
least one further table containing information 
relating to persons whose details are stored in 
the personal information table; and 

(b) a plurality of clients, for accessing said da- 
tabase; characterised in that 

(c) said tables in said database have keys that 
are unrelated to each other, whereby it is im- 
possible to determine solely from information in 
the server which record in said f u rther table cor- 
responds to which record in said personal in- 
formation table; and 

(d) each client includes an encryption process 
for converting a personal identifier value, which 
identifies a record relating to a particular person 
in said personal information table, into a pseu- 
do-identifier value, which identifies a record re- 
lating to the same person in said further table. 

2. A computer system according to Claim 1 wherein 
said encryption process uses a different encryption 
protocol for each said pseudo-identifier value. 

3. A computer system according to Claim 2 wherein 
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the encryption process uses the following parame- 
ters: 

the personal identifier value being encrypted, 
an encryption key, and 

a unique identifier number for the pseudo-iden- 
tifier. 



said client encrypts text before writing it into said 
free text table and decrypts text when read from 
said free text table. 

1 0. A method according to any of Claims 6 - 9 wherein 
information is encrypted while in transit between 
said client and said server. 



4. A computer system according to any preceding 
claim wherein the database includes at least one io 
free text table containing free text information, and 
wherein said client includes means for encrypting 
text before writing it into said free text table and for 
decrypting text when read from said free text table. 

75 

5. A computer system according to any preceding 
claim including means for encrypting information 
while in transit between said client and said server. 



6. A method of securely storing data in a database, 20 
comprising: 



(a) storing in a server a database including at 
least one personal information table and at 
least one further table containing information 25 
relating to persons whose details are stored in 

the personal information table; 

(b) providing said tables with keys that are un- 
related to each other, whereby it is impossible 

to determine solely from information in the serv- 30 
er which record in said further table corre- 
sponds to which record in said personal infor- 
mation table; 

(c) operating a plurality of clients to access said 
database; and 35 

(d) performing, in each said client, an encryp- 
tion process which converts a personal identi- 
fier value, identifying a record relating to a par- 
ticular person in said personal information ta- 
ble, into a pseudo-identifier value, which iden- 40 
tifies a record relating to the same person in 
said further table. 



7. A method according to Claim 6 wherein a different 
encryption protocol is used for each said pseudo- 45 
identifier value. 



8. A method according to Claim 7 wherein said encryp- 
tion process uses the following parameters: 

the personal identifier value being encrypted, 
an encryption key, and 

a unique identifier number for the pseudo-iden- 
tifier. 

9. A method according to any of Claims 6 to 8 wherein 
said database includes at least one free text table 
containing free text information, and wherein each 
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